| Package | Code Size | Bugs | Bugs p1 | Bugs p2 | Bugs p3 | Bugs Exp. | Ratio |
|---|---|---|---|---|---|---|---|
| Overall (2265 packages), (33353 classes) | 2099678 | 1603 | 1603 | ||||
| com.ctc.wstx.cfg | 204 | 59 | 59 | ||||
| com.ctc.wstx.dtd | 4062 | 6 | 6 | ||||
| com.ctc.wstx.io | 2739 | 1 | 1 | ||||
| com.ctc.wstx.sr | 4583 | 2 | 2 | ||||
| com.ctc.wstx.util | 2381 | 2 | 2 | ||||
| com.sun.codemodel | 2980 | 1 | 1 | ||||
| com.sun.connector.jaxr | 576 | 1 | 1 | ||||
| com.sun.corba.ee.impl.activation | 1672 | 1 | 1 | ||||
| com.sun.corba.ee.impl.dynamicany | 1954 | 14 | 14 | ||||
| com.sun.corba.ee.impl.encoding | 6304 | 2 | 2 | ||||
| com.sun.corba.ee.impl.ior | 1174 | 2 | 2 | ||||
| com.sun.corba.ee.impl.naming.pcosnaming | 689 | 1 | 1 | ||||
| com.sun.corba.ee.impl.orb | 2541 | 1 | 1 | ||||
| com.sun.corba.ee.impl.presentation.rmi | 1741 | 1 | 1 | ||||
| com.sun.corba.ee.impl.protocol.giopmsgheaders | 1933 | 1 | 1 | ||||
| com.sun.corba.ee.org.apache.bcel | 459 | 11 | 11 | ||||
| com.sun.corba.ee.org.apache.bcel.classfile | 3202 | 1 | 1 | ||||
| com.sun.corba.ee.org.apache.bcel.generic | 6553 | 6 | 6 | ||||
| com.sun.corba.ee.org.apache.bcel.util | 1580 | 3 | 3 | ||||
| com.sun.corba.ee.org.apache.bcel.verifier | 933 | 3 | 3 | ||||
| com.sun.corba.ee.org.apache.bcel.verifier.structurals | 2750 | 5 | 5 | ||||
| com.sun.corba.ee.org.objectweb.asm.attrs | 168 | 1 | 1 | ||||
| com.sun.corba.ee.org.objectweb.asm.tree.analysis | 1042 | 2 | 2 | ||||
| com.sun.corba.ee.org.objectweb.asm.util | 1955 | 1 | 1 | ||||
| com.sun.corba.ee.spi.orbutil.generic | 331 | 1 | 1 | ||||
| com.sun.data.provider | 255 | 2 | 2 | ||||
| com.sun.data.provider.impl | 3429 | 10 | 10 | ||||
| com.sun.dtdparser | 2392 | 2 | 2 | ||||
| com.sun.ejb.containers | 10231 | 1 | 1 | ||||
| com.sun.ejb.ee.sfsb.store | 3343 | 2 | 2 | ||||
| com.sun.ejb.portable | 164 | 1 | 1 | ||||
| com.sun.enterprise.admin.common.domains.registry | 461 | 1 | 1 | ||||
| com.sun.enterprise.admin.monitor.callflow | 3244 | 1 | 1 | ||||
| com.sun.enterprise.admin.monitor.registry | 294 | 2 | 2 | ||||
| com.sun.enterprise.admin.server.core.mbean.config | 4708 | 2 | 2 | ||||
| com.sun.enterprise.admin.target | 385 | 1 | 1 | ||||
| com.sun.enterprise.appclient.jws | 2023 | 2 | 2 | ||||
| com.sun.enterprise.cli.commands | 5773 | 1 | 1 | ||||
| com.sun.enterprise.cli.commands.monitor | 1725 | 1 | 1 | ||||
| com.sun.enterprise.config | 987 | 3 | 3 | ||||
| com.sun.enterprise.config.clientbeans | 1461 | 10 | 10 | ||||
| com.sun.enterprise.config.impl | 694 | 2 | 2 | ||||
| com.sun.enterprise.config.serverbeans | 18497 | 36 | 36 | ||||
| com.sun.enterprise.connectors | 3239 | 2 | 2 | ||||
| com.sun.enterprise.connectors.system | 1294 | 1 | 1 | ||||
| com.sun.enterprise.deployapi | 1465 | 4 | 4 | ||||
| com.sun.enterprise.deployment | 12216 | 2 | 2 | ||||
| com.sun.enterprise.ee.admin.hadbmgmt | 2742 | 1 | 1 | ||||
| com.sun.enterprise.ee.ejb.iiop | 174 | 1 | 1 | ||||
| com.sun.enterprise.ee.web.sessmgmt | 13203 | 14 | 14 | ||||
| com.sun.enterprise.iiop | 2906 | 3 | 3 | ||||
| com.sun.enterprise.iiop.security | 1973 | 3 | 3 | ||||
| com.sun.enterprise.loader | 888 | 2 | 2 | ||||
| com.sun.enterprise.management.agent | 1048 | 1 | 1 | ||||
| com.sun.enterprise.management.j2ee | 816 | 1 | 1 | ||||
| com.sun.enterprise.management.model | 1251 | 1 | 1 | ||||
| com.sun.enterprise.management.support | 5592 | 2 | 2 | ||||
| com.sun.enterprise.security.application | 491 | 1 | 1 | ||||
| com.sun.enterprise.security.jmac.callback | 394 | 1 | 1 | ||||
| com.sun.enterprise.server | 4575 | 2 | 2 | ||||
| com.sun.enterprise.server.ondemand | 808 | 3 | 3 | ||||
| com.sun.enterprise.tools.admingui.handlers | 12249 | 3 | 3 | ||||
| com.sun.enterprise.tools.admingui.util | 752 | 1 | 1 | ||||
| com.sun.enterprise.tools.upgrade.transform | 437 | 1 | 1 | ||||
| com.sun.enterprise.tools.verifier.apiscan.classfile | 1061 | 1 | 1 | ||||
| com.sun.enterprise.tools.verifier.apiscan.packaging | 416 | 2 | 2 | ||||
| com.sun.enterprise.tools.verifier.apiscan.stdapis | 357 | 1 | 1 | ||||
| com.sun.enterprise.tools.verifier.gui | 785 | 8 | 8 | ||||
| com.sun.enterprise.tools.verifier.tests.connector | 547 | 1 | 1 | ||||
| com.sun.enterprise.tools.verifier.tests.ejb | 1243 | 1 | 1 | ||||
| com.sun.enterprise.tools.verifier.tests.ejb.elements | 471 | 1 | 1 | ||||
| com.sun.enterprise.tools.verifier.tests.ejb.runtime | 1078 | 2 | 2 | ||||
| com.sun.enterprise.tools.verifier.tests.ejb.runtime.resource | 190 | 2 | 2 | ||||
| com.sun.enterprise.tools.verifier.tests.web.runtime | 1029 | 2 | 2 | ||||
| com.sun.enterprise.tools.verifier.tests.webservices | 946 | 1 | 1 | ||||
| com.sun.enterprise.transaction | 357 | 1 | 1 | ||||
| com.sun.enterprise.update.config.beans | 4240 | 22 | 22 | ||||
| com.sun.enterprise.update.desktop | 108 | 2 | 2 | ||||
| com.sun.enterprise.update.repository | 170 | 1 | 1 | ||||
| com.sun.enterprise.update.ui | 2816 | 1 | 1 | ||||
| com.sun.enterprise.util.collection | 1602 | 1 | 1 | ||||
| com.sun.enterprise.util.io | 901 | 1 | 1 | ||||
| com.sun.enterprise.web | 7552 | 3 | 3 | ||||
| com.sun.enterprise.web.ara.rules | 275 | 2 | 2 | ||||
| com.sun.enterprise.web.connector.grizzly | 5043 | 3 | 3 | ||||
| com.sun.enterprise.webservice | 4250 | 1 | 1 | ||||
| com.sun.enterprise.webservice.monitoring | 818 | 1 | 1 | ||||
| com.sun.faces.config.beans | 1056 | 1 | 1 | ||||
| com.sun.faces.extensions.avatar.components | 540 | 1 | 1 | ||||
| com.sun.faces.extensions.avatar.event | 214 | 1 | 1 | ||||
| com.sun.faces.renderkit | 763 | 1 | 1 | ||||
| com.sun.genericra | 493 | 1 | 1 | ||||
| com.sun.genericra.monitoring | 194 | 1 | 1 | ||||
| com.sun.grizzly.cometd | 306 | 1 | 1 | ||||
| com.sun.grizzly.cometd.bayeux | 427 | 1 | 1 | ||||
| com.sun.hadb.cli | 1782 | 3 | 3 | ||||
| com.sun.hadb.cli.adapter | 2444 | 2 | 2 | ||||
| com.sun.hadb.cli.framework | 2523 | 7 | 7 | ||||
| com.sun.hadb.jdbc | 8755 | 8 | 8 | ||||
| com.sun.hadb.jdbc.ds | 179 | 1 | 1 | ||||
| com.sun.hadb.jdbc.pool | 587 | 4 | 4 | ||||
| com.sun.hadb.mgt | 1528 | 1 | 1 | ||||
| com.sun.hadb.mgt.agent | 3965 | 3 | 3 | ||||
| com.sun.hadb.mgt.api | 4163 | 1 | 1 | ||||
| com.sun.hadb.mgt.cluma | 1985 | 3 | 3 | ||||
| com.sun.hadb.mgt.rema | 10119 | 6 | 6 | ||||
| com.sun.java.help.impl | 2627 | 7 | 7 | ||||
| com.sun.java.help.search | 4944 | 12 | 12 | ||||
| com.sun.jbi.framework | 4944 | 1 | 1 | ||||
| com.sun.jbi.jsf.configuration.beans | 795 | 6 | 6 | ||||
| com.sun.jbi.jsf.configuration.xml.schema | 201 | 2 | 2 | ||||
| com.sun.jbi.jsf.framework.model | 561 | 4 | 4 | ||||
| com.sun.jbi.jsf.framework.services.administration.providers | 374 | 3 | 3 | ||||
| com.sun.jbi.jsf.framework.services.configuration.providers.glassfish | 121 | 2 | 2 | ||||
| com.sun.jbi.jsf.framework.services.management.providers | 97 | 2 | 2 | ||||
| com.sun.jbi.jsf.framework.services.statistics.providers | 194 | 1 | 1 | ||||
| com.sun.jbi.jsf.statistics | 358 | 1 | 1 | ||||
| com.sun.jbi.management | 697 | 1 | 1 | ||||
| com.sun.jbi.management.registry | 602 | 1 | 1 | ||||
| com.sun.jbi.management.registry.data | 212 | 1 | 1 | ||||
| com.sun.jbi.management.registry.xml | 2821 | 1 | 1 | ||||
| com.sun.jbi.management.repository | 651 | 1 | 1 | ||||
| com.sun.jbi.management.support | 761 | 1 | 1 | ||||
| com.sun.jbi.management.system | 4370 | 4 | 4 | ||||
| com.sun.jbi.management.util | 797 | 2 | 2 | ||||
| com.sun.jbi.messaging | 2284 | 2 | 2 | ||||
| com.sun.jbi.ui.runtime.mbeans | 3135 | 2 | 2 | ||||
| com.sun.jdmk | 3661 | 1 | 1 | ||||
| com.sun.jdmk.cascading | 458 | 3 | 3 | ||||
| com.sun.jdmk.comm | 10938 | 8 | 8 | ||||
| com.sun.jdmk.discovery | 1690 | 10 | 10 | ||||
| com.sun.jdmk.internal | 816 | 3 | 3 | ||||
| com.sun.jdo.api.persistence.enhancer.classfile | 3169 | 4 | 4 | ||||
| com.sun.jdo.api.persistence.enhancer.generator | 511 | 5 | 5 | ||||
| com.sun.jdo.api.persistence.enhancer.impl | 2005 | 2 | 2 | ||||
| com.sun.jdo.api.persistence.mapping.ejb | 1281 | 1 | 1 | ||||
| com.sun.jdo.api.persistence.model | 761 | 3 | 3 | ||||
| com.sun.jdo.spi.persistence.support.ejb.cmp | 517 | 1 | 1 | ||||
| com.sun.jdo.spi.persistence.support.ejb.ejbqlc | 7396 | 10 | 10 | ||||
| com.sun.jdo.spi.persistence.support.sqlstore.sco | 1151 | 6 | 6 | ||||
| com.sun.jdo.spi.persistence.utility.generator | 169 | 1 | 1 | ||||
| com.sun.jmaki | 1617 | 5 | 5 | ||||
| com.sun.jmaki.services | 433 | 1 | 1 | ||||
| com.sun.jmx.remote.generic | 902 | 1 | 1 | ||||
| com.sun.jndi.toolkit.ctx | 1590 | 2 | 2 | ||||
| com.sun.jndi.url.jndi | 138 | 1 | 1 | ||||
| com.sun.jsftemplating.component.dataprovider | 385 | 1 | 1 | ||||
| com.sun.jsftemplating.el | 999 | 1 | 1 | ||||
| com.sun.jsftemplating.layout.template | 862 | 1 | 1 | ||||
| com.sun.jsftemplating.util | 1032 | 2 | 2 | ||||
| com.sun.jts.CosTransactions | 9156 | 8 | 8 | ||||
| com.sun.management.comm | 5065 | 8 | 8 | ||||
| com.sun.management.internal.snmp | 1139 | 1 | 1 | ||||
| com.sun.management.snmp | 3181 | 1 | 1 | ||||
| com.sun.management.snmp.agent | 3857 | 3 | 3 | ||||
| com.sun.management.snmp.IPAcl | 3391 | 1 | 1 | ||||
| com.sun.management.snmp.manager | 3322 | 12 | 12 | ||||
| com.sun.management.snmp.uacl | 2047 | 1 | 1 | ||||
| com.sun.management.snmp.usm | 2137 | 1 | 1 | ||||
| com.sun.management.snmp.usm.usmmib | 1599 | 7 | 7 | ||||
| com.sun.messaging.jmq.io | 6231 | 3 | 3 | ||||
| com.sun.messaging.jmq.jmsclient | 12480 | 2 | 2 | ||||
| com.sun.messaging.jmq.jmsserver | 2499 | 1 | 1 | ||||
| com.sun.messaging.jmq.jmsserver.data | 2590 | 2 | 2 | ||||
| com.sun.messaging.jmq.jmsserver.data.handlers | 3632 | 1 | 1 | ||||
| com.sun.messaging.jmq.jmsserver.multibroker | 1344 | 1 | 1 | ||||
| com.sun.messaging.jmq.jmsserver.multibroker.fullyconnected | 2176 | 1 | 1 | ||||
| com.sun.messaging.jmq.jmsserver.persist.file | 4475 | 1 | 1 | ||||
| com.sun.messaging.jms.ra | 9240 | 5 | 5 | ||||
| com.sun.mfwk.agent.appserv.lifecycle.beans | 1032 | 4 | 4 | ||||
| com.sun.mfwk.agent.appserv.util | 121 | 2 | 2 | ||||
| com.sun.msv.datatype.xsd | 2568 | 2 | 2 | ||||
| com.sun.msv.grammar.util | 340 | 3 | 3 | ||||
| com.sun.msv.reader.datatype.xsd | 417 | 1 | 1 | ||||
| com.sun.msv.reader.trex.ng | 994 | 3 | 3 | ||||
| com.sun.msv.scanner.dtd | 2340 | 2 | 2 | ||||
| com.sun.msv.writer.relaxng | 580 | 1 | 1 | ||||
| com.sun.org.apache.commons.beanutils | 2210 | 3 | 3 | ||||
| com.sun.org.apache.commons.collections | 6137 | 4 | 4 | ||||
| com.sun.org.apache.commons.digester | 1874 | 5 | 5 | ||||
| com.sun.org.apache.commons.digester.rss | 535 | 1 | 1 | ||||
| com.sun.org.apache.commons.logging | 280 | 2 | 2 | ||||
| com.sun.org.apache.commons.logging.impl | 498 | 2 | 2 | ||||
| com.sun.org.apache.commons.modeler | 1841 | 2 | 2 | ||||
| com.sun.org.apache.commons.modeler.util | 615 | 1 | 1 | ||||
| com.sun.org.apache.xml.internal.resolver | 1510 | 4 | 4 | ||||
| com.sun.org.apache.xml.internal.resolver.helpers | 194 | 1 | 1 | ||||
| com.sun.org.apache.xml.internal.security.c14n.implementations | 778 | 1 | 1 | ||||
| com.sun.org.apache.xml.internal.security.encryption | 1598 | 3 | 3 | ||||
| com.sun.org.apache.xml.internal.security.keys.content.x509 | 180 | 5 | 5 | ||||
| com.sun.org.apache.xml.internal.security.utils | 1651 | 3 | 3 | ||||
| com.sun.tools.jxc.gen.config | 1065 | 11 | 11 | ||||
| com.sun.tools.ws.processor.modeler.wsdl | 2533 | 5 | 5 | ||||
| com.sun.tools.ws.wscompile | 1054 | 2 | 2 | ||||
| com.sun.tools.ws.wsdl.document.jaxws | 227 | 1 | 1 | ||||
| com.sun.tools.xjc | 1815 | 1 | 1 | ||||
| com.sun.tools.xjc.generator.util | 62 | 3 | 3 | ||||
| com.sun.tools.xjc.reader | 682 | 1 | 1 | ||||
| com.sun.tools.xjc.reader.gbind | 276 | 1 | 1 | ||||
| com.sun.tools.xjc.reader.xmlschema.bindinfo.parser | 4293 | 60 | 60 | ||||
| com.sun.webui.jsf.component | 39020 | 36 | 36 | ||||
| com.sun.webui.jsf.event | 586 | 2 | 2 | ||||
| com.sun.webui.jsf.model | 1518 | 3 | 3 | ||||
| com.sun.webui.jsf.model.scheduler | 226 | 2 | 2 | ||||
| com.sun.webui.jsf.renderkit.html | 10807 | 2 | 2 | ||||
| com.sun.webui.jsf.util | 2806 | 3 | 3 | ||||
| com.sun.webui.jsf.validator | 264 | 1 | 1 | ||||
| com.sun.xml.bind | 1046 | 2 | 2 | ||||
| com.sun.xml.bind.unmarshaller | 906 | 1 | 1 | ||||
| com.sun.xml.bind.util | 365 | 2 | 2 | ||||
| com.sun.xml.bind.v2 | 225 | 1 | 1 | ||||
| com.sun.xml.bind.v2.runtime | 3049 | 2 | 2 | ||||
| com.sun.xml.bind.v2.runtime.unmarshaller | 2318 | 2 | 2 | ||||
| com.sun.xml.bind.v2.schemagen | 1029 | 2 | 2 | ||||
| com.sun.xml.bind.v2.util | 488 | 1 | 1 | ||||
| com.sun.xml.dtdparser | 2350 | 2 | 2 | ||||
| com.sun.xml.fastinfoset.algorithm | 931 | 1 | 1 | ||||
| com.sun.xml.fastinfoset.sax | 1656 | 1 | 1 | ||||
| com.sun.xml.fastinfoset.util | 1473 | 1 | 1 | ||||
| com.sun.xml.messaging.saaj.client.p2p | 386 | 3 | 3 | ||||
| com.sun.xml.messaging.saaj.soap | 2132 | 11 | 11 | ||||
| com.sun.xml.messaging.saaj.soap.impl | 1639 | 5 | 5 | ||||
| com.sun.xml.messaging.saaj.soap.name | 243 | 2 | 2 | ||||
| com.sun.xml.messaging.saaj.soap.ver1_1 | 535 | 5 | 5 | ||||
| com.sun.xml.messaging.saaj.soap.ver1_2 | 813 | 7 | 7 | ||||
| com.sun.xml.messaging.saaj.util | 1250 | 4 | 4 | ||||
| com.sun.xml.messaging.saaj.util.transform | 170 | 1 | 1 | ||||
| com.sun.xml.registry.common.tools | 686 | 2 | 2 | ||||
| com.sun.xml.registry.uddi | 4893 | 4 | 4 | ||||
| com.sun.xml.registry.uddi.infomodel | 1388 | 1 | 1 | ||||
| com.sun.xml.rpc.client.dii | 1892 | 2 | 2 | ||||
| com.sun.xml.rpc.encoding | 3785 | 4 | 4 | ||||
| com.sun.xml.rpc.encoding.literal | 1887 | 4 | 4 | ||||
| com.sun.xml.rpc.encoding.soap | 1716 | 4 | 4 | ||||
| com.sun.xml.rpc.processor.generator | 10633 | 9 | 9 | ||||
| com.sun.xml.rpc.processor.generator.nodes | 910 | 2 | 2 | ||||
| com.sun.xml.rpc.processor.modeler.j2ee.xml | 2371 | 1 | 1 | ||||
| com.sun.xml.rpc.processor.modeler.wsdl | 4848 | 3 | 3 | ||||
| com.sun.xml.rpc.server.http | 994 | 1 | 1 | ||||
| com.sun.xml.rpc.sp | 5458 | 3 | 3 | ||||
| com.sun.xml.rpc.streaming | 2335 | 1 | 1 | ||||
| com.sun.xml.rpc.tools.ant | 585 | 9 | 9 | ||||
| com.sun.xml.rpc.tools.wsdeploy | 1300 | 1 | 1 | ||||
| com.sun.xml.rpc.util | 1568 | 8 | 8 | ||||
| com.sun.xml.stream | 6950 | 6 | 6 | ||||
| com.sun.xml.stream.dtd.nonvalidating | 602 | 2 | 2 | ||||
| com.sun.xml.stream.util | 97 | 3 | 3 | ||||
| com.sun.xml.stream.xerces.impl.io | 454 | 1 | 1 | ||||
| com.sun.xml.stream.xerces.util | 3301 | 9 | 9 | ||||
| com.sun.xml.txw2.output | 1182 | 1 | 1 | ||||
| com.sun.xml.ws.api.message | 666 | 1 | 1 | ||||
| com.sun.xml.ws.client | 983 | 1 | 1 | ||||
| com.sun.xml.ws.model | 1422 | 1 | 1 | ||||
| com.sun.xml.ws.rm.jaxws.util | 73 | 1 | 1 | ||||
| com.sun.xml.ws.runtime.util | 92 | 2 | 2 | ||||
| com.sun.xml.ws.security.impl.policy | 3992 | 1 | 1 | ||||
| com.sun.xml.ws.security.opt.crypto.dsig | 857 | 1 | 1 | ||||
| com.sun.xml.ws.security.opt.crypto.jaxb | 317 | 1 | 1 | ||||
| com.sun.xml.ws.security.opt.impl.dsig | 1514 | 6 | 6 | ||||
| com.sun.xml.ws.security.opt.impl.incoming | 4019 | 2 | 2 | ||||
| com.sun.xml.ws.security.opt.impl.keyinfo | 1049 | 3 | 3 | ||||
| com.sun.xml.ws.security.opt.impl.tokens | 391 | 1 | 1 | ||||
| com.sun.xml.ws.security.opt.impl.util | 1562 | 1 | 1 | ||||
| com.sun.xml.ws.security.trust | 264 | 6 | 6 | ||||
| com.sun.xml.ws.server | 1407 | 2 | 2 | ||||
| com.sun.xml.ws.spi | 85 | 1 | 1 | ||||
| com.sun.xml.ws.transport.http | 704 | 1 | 1 | ||||
| com.sun.xml.ws.transport.tcp.server.glassfish | 540 | 1 | 1 | ||||
| com.sun.xml.ws.util.xml | 652 | 1 | 1 | ||||
| com.sun.xml.wss.core | 2952 | 2 | 2 | ||||
| com.sun.xml.wss.impl | 3131 | 1 | 1 | ||||
| com.sun.xml.wss.impl.filter | 1091 | 1 | 1 | ||||
| com.sun.xml.wss.impl.policy.mls | 1894 | 1 | 1 | ||||
| com.sun.xml.wss.saml.internal.saml11.jaxb10.impl | 16275 | 240 | 240 | ||||
| com.sun.xml.xsom.impl.parser.state | 7048 | 1 | 1 | ||||
| javanet.staxutils | 3034 | 6 | 6 | ||||
| javanet.staxutils.io | 711 | 1 | 1 | ||||
| javax.faces.application | 415 | 1 | 1 | ||||
| javax.help | 6809 | 8 | 8 | ||||
| javax.help.plaf.basic | 3654 | 2 | 2 | ||||
| javax.management | 3214 | 5 | 5 | ||||
| javax.management.modelmbean | 2507 | 2 | 2 | ||||
| javax.management.relation | 3027 | 3 | 3 | ||||
| javax.management.remote | 646 | 1 | 1 | ||||
| javax.management.remote.jmxmp | 58 | 1 | 1 | ||||
| javax.servlet.jsp.jstl.core | 448 | 1 | 1 | ||||
| javax.servlet.jsp.tagext | 613 | 1 | 1 | ||||
| javax.xml.bind | 1387 | 2 | 2 | ||||
| javax.xml.registry.samples | 125 | 1 | 1 | ||||
| net.jxta.impl.cm | 1660 | 1 | 1 | ||||
| net.jxta.impl.document | 1355 | 5 | 5 | ||||
| net.jxta.impl.endpoint.cbjx | 457 | 2 | 2 | ||||
| net.jxta.impl.endpoint.relay | 1752 | 1 | 1 | ||||
| net.jxta.impl.endpoint.tls | 1635 | 1 | 1 | ||||
| net.jxta.impl.id.binaryID | 689 | 3 | 3 | ||||
| net.jxta.impl.peergroup | 2971 | 1 | 1 | ||||
| net.jxta.impl.rendezvous | 1130 | 1 | 1 | ||||
| net.jxta.impl.resolver.resolverMeter | 1718 | 1 | 1 | ||||
| oracle.toplink.essentials.descriptors | 3718 | 10 | 10 | ||||
| oracle.toplink.essentials.exceptions | 4794 | 1 | 1 | ||||
| oracle.toplink.essentials.internal.descriptors | 1747 | 1 | 1 | ||||
| oracle.toplink.essentials.internal.ejb.cmp3.metadata | 1556 | 9 | 9 | ||||
| oracle.toplink.essentials.internal.ejb.cmp3.metadata.sequencing | 117 | 3 | 3 | ||||
| oracle.toplink.essentials.internal.ejb.cmp3.transaction.base | 363 | 1 | 1 | ||||
| oracle.toplink.essentials.internal.ejb.cmp3.xml.accessors | 523 | 6 | 6 | ||||
| oracle.toplink.essentials.internal.helper | 4357 | 5 | 5 | ||||
| oracle.toplink.essentials.internal.identitymaps | 1247 | 1 | 1 | ||||
| oracle.toplink.essentials.internal.queryframework | 3754 | 1 | 1 | ||||
| oracle.toplink.essentials.internal.sessions | 5820 | 2 | 2 | ||||
| oracle.toplink.essentials.mappings | 5754 | 17 | 17 | ||||
| oracle.toplink.essentials.mappings.converters | 347 | 1 | 1 | ||||
| oracle.toplink.essentials.queryframework | 3855 | 6 | 6 | ||||
| oracle.toplink.essentials.sequencing | 532 | 4 | 4 | ||||
| org.apache.bcel | 483 | 11 | 11 | ||||
| org.apache.bcel.classfile | 3172 | 1 | 1 | ||||
| org.apache.bcel.generic | 6517 | 6 | 6 | ||||
| org.apache.bcel.util | 1550 | 3 | 3 | ||||
| org.apache.bcel.verifier | 926 | 3 | 3 | ||||
| org.apache.bcel.verifier.structurals | 2700 | 5 | 5 | ||||
| org.apache.catalina.authenticator | 1049 | 1 | 1 | ||||
| org.apache.catalina.core | 10576 | 3 | 3 | ||||
| org.apache.catalina.mbeans | 3068 | 1 | 1 | ||||
| org.apache.catalina.session | 2894 | 1 | 1 | ||||
| org.apache.catalina.ssi | 1518 | 1 | 1 | ||||
| org.apache.catalina.util | 2913 | 5 | 5 | ||||
| org.apache.commons.fileupload.disk | 203 | 1 | 1 | ||||
| org.apache.commons.logging | 278 | 2 | 2 | ||||
| org.apache.commons.logging.impl | 703 | 1 | 1 | ||||
| org.apache.coyote.http11 | 1674 | 1 | 1 | ||||
| org.apache.jasper | 1539 | 1 | 1 | ||||
| org.apache.naming.factory | 317 | 1 | 1 | ||||
| org.apache.regexp | 1584 | 1 | 1 | ||||
| org.apache.xml.resolver | 1098 | 3 | 3 | ||||
| org.apache.xml.resolver.apps | 413 | 1 | 1 | ||||
| org.apache.xml.resolver.tools | 331 | 2 | 2 | ||||
| org.apache.xmlbeans | 7284 | 1 | 1 | ||||
| org.apache.xmlbeans.impl.common | 3933 | 4 | 4 | ||||
| org.apache.xmlbeans.impl.config | 595 | 2 | 2 | ||||
| org.apache.xmlbeans.impl.jam.internal | 980 | 1 | 1 | ||||
| org.apache.xmlbeans.impl.jam.internal.parser | 136 | 1 | 1 | ||||
| org.apache.xmlbeans.impl.piccolo.util | 246 | 1 | 1 | ||||
| org.apache.xmlbeans.impl.piccolo.xml | 5308 | 4 | 4 | ||||
| org.apache.xmlbeans.impl.regex | 4226 | 1 | 1 | ||||
| org.apache.xmlbeans.impl.schema | 12921 | 5 | 5 | ||||
| org.apache.xmlbeans.impl.store | 14490 | 6 | 6 | ||||
| org.apache.xmlbeans.impl.tool | 4527 | 8 | 8 | ||||
| org.apache.xmlbeans.impl.util | 655 | 3 | 3 | ||||
| org.apache.xmlbeans.impl.values | 4378 | 4 | 4 | ||||
| org.apache.xmlbeans.impl.xsd2inst | 724 | 3 | 3 | ||||
| org.javagroups | 1670 | 3 | 3 | ||||
| org.javagroups.blocks | 6508 | 12 | 12 | ||||
| org.javagroups.debug | 293 | 2 | 2 | ||||
| org.javagroups.demos | 3842 | 13 | 13 | ||||
| org.javagroups.demos.applets | 213 | 3 | 3 | ||||
| org.javagroups.demos.wb | 586 | 1 | 1 | ||||
| org.javagroups.ensemble | 1048 | 5 | 5 | ||||
| org.javagroups.log | 635 | 1 | 1 | ||||
| org.javagroups.persistence | 461 | 1 | 1 | ||||
| org.javagroups.protocols | 11130 | 14 | 14 | ||||
| org.javagroups.protocols.pbcast | 3417 | 3 | 3 | ||||
| org.javagroups.protocols.ring | 398 | 5 | 5 | ||||
| org.javagroups.stack | 3087 | 4 | 4 | ||||
| org.javagroups.tests | 7132 | 11 | 11 | ||||
| org.javagroups.util | 2000 | 8 | 8 | ||||
| org.jcp.xml.dsig.internal.dom | 2962 | 16 | 16 | ||||
| org.jdesktop.jdic.browser | 976 | 4 | 4 | ||||
| org.jdesktop.jdic.desktop.internal.impl | 860 | 2 | 2 | ||||
| org.jdesktop.jdic.filetypes.internal | 1050 | 1 | 1 | ||||
| org.jgroups | 1793 | 6 | 6 | ||||
| org.jgroups.blocks | 6743 | 18 | 18 | ||||
| org.jgroups.conf | 789 | 3 | 3 | ||||
| org.jgroups.debug | 307 | 2 | 2 | ||||
| org.jgroups.ensemble | 1075 | 5 | 5 | ||||
| org.jgroups.persistence | 536 | 1 | 1 | ||||
| org.jgroups.protocols | 12716 | 10 | 10 | ||||
| org.jgroups.protocols.pbcast | 3618 | 4 | 4 | ||||
| org.jgroups.protocols.ring | 405 | 5 | 5 | ||||
| org.jgroups.stack | 3953 | 10 | 10 | ||||
| org.jgroups.util | 3051 | 20 | 20 | ||||
| org.kohsuke.rngom.digested | 1301 | 3 | 3 | ||||
| org.kohsuke.rngom.dt | 68 | 1 | 1 | ||||
| org.netbeans.modules.dbschema | 1532 | 3 | 3 | ||||
| org.netbeans.modules.dbschema.jdbcimpl | 1449 | 1 | 1 | ||||
| org.netbeans.modules.dbschema.migration.archiver.deserializer | 810 | 3 | 3 | ||||
| org.netbeans.modules.schema2beans | 6691 | 6 | 6 | ||||
| org.netbeans.modules.schema2beansdev | 17556 | 6 | 6 | ||||
| org.netbeans.modules.schema2beansdev.beangraph | 700 | 2 | 2 | ||||
| org.netbeans.modules.schema2beansdev.metadd | 2095 | 3 | 3 | ||||
| sun.rmi.rmic.iiop | 5883 | 1 | 1 |
This code creates a java.util.Random object, uses it to generate one random number, and then discards the Random object. This produces mediocre quality random numbers and is inefficient. If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number is required invoke a method on the existing Random object to obtain it.
If it is important that the generated Random numbers not be guessable, you must not create a new Random for each random number; the values are too easily guessable. You should strongly consider using a java.security.SecureRandom instead (and avoid allocating a new SecureRandom for each random number needed).
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This class defines a covariant version of the equals()
method, but inherits the normal equals(Object) method
defined in the base java.lang.Object class.
The class should probably define a non-covariant version of equals().
(I.e., a method with the signature boolean equals(java.lang.Object).
This class defines a covariant version of the equals()
method, but inherits the normal equals(Object) method
defined in the base java.lang.Object class.
The class should probably define a non-covariant version of equals().
(I.e., a method with the signature boolean equals(java.lang.Object).
This class defines a covariant version of the equals()
method, but inherits the normal equals(Object) method
defined in the base java.lang.Object class.
The class should probably define a non-covariant version of equals().
(I.e., a method with the signature boolean equals(java.lang.Object).
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This finalizer does nothing except null out fields. This is completely pointless, and requires that the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize method.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class is an inner class of a non-serializable class. Thus, attempts to serialize it will also attempt to associate instance of the outer class with which it is associated, leading to a runtime error.
If possible, making the inner class a static inner class should solve the problem. Making the outer class serializable might also work, but that would mean serializing an instance of the inner class would always also serialize the instance of the outer class, which it often not what you really want.
A non-serializable value is stored into a non-transient field of a serializable class.
A non-serializable value is stored into a non-transient field of a serializable class.
A non-serializable value is stored into a non-transient field of a serializable class.
A non-serializable value is stored into a non-transient field of a serializable class.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This method invokes the .equals(Object o) to compare an array and a reference that doesn't seem to be an array. If things being compared are of different types, they are guaranteed to be unequal and the comparison is almost certainly an error. Even if they are both arrays, the equals method on arrays only determines of the two arrays are the same object. To compare the contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).
This method calls equals(Object) on two references, one of which is a class and the other an interface, where neither the class nor any of its non-abstract subclasses implement the interface. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
A class defines an equals(Object) method but not a hashCode() method, and thus doesn't fulfill the requirement that equal Objects have equal hashCodes. An instance of this class is used in a hash data structure, making the need to fix this problem of highest importance.
A class defines an equals(Object) method but not a hashCode() method, and thus doesn't fulfill the requirement that equal Objects have equal hashCodes. An instance of this class is used in a hash data structure, making the need to fix this problem of highest importance.
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
This method unconditionally invokes itself. This would seem to indicate an infinite recursive loop that will result in a stack overflow.
This method unconditionally invokes itself. This would seem to indicate an infinite recursive loop that will result in a stack overflow.
This code compares a value that is guaranteed to be non-negative with a negative constant.
This code compares a value that is guaranteed to be non-negative with a negative constant.
Signed bytes can only have a value in the range -128 to 127. Comparing
a signed byte with a value outside that range is vacuous and likely to be incorrect.
To convert a signed byte b to an unsigned value in the range 0..255,
use 0xff & b
Signed bytes can only have a value in the range -128 to 127. Comparing
a signed byte with a value outside that range is vacuous and likely to be incorrect.
To convert a signed byte b to an unsigned value in the range 0..255,
use 0xff & b
The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.
The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.
The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a method called hashcode(). This method
does not override the hashCode() method in java.lang.Object,
which is probably what was intended.
This class defines a method called hashcode(). This method
does not override the hashCode() method in java.lang.Object,
which is probably what was intended.
The referenced methods have names that differ only by capitalization or the packages of their parameters. This is very confusing because if the capitalization and parameter package names were identical then one of the methods would override the other.
The referenced methods have names that differ only by capitalization or the packages of their parameters. This is very confusing because if the capitalization and parameter package names were identical then one of the methods would override the other.
The referenced methods have names that differ only by capitalization or the packages of their parameters. This is very confusing because if the capitalization and parameter package names were identical then one of the methods would override the other.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
This method compares a local variable with itself, and may indicate a typo or a logic error. Make sure that you are comparing the right things.
A value stored in the previous switch case is overwritten here due to a switch fall through. It is likely that you forgot to put a break or return at the end of the previous case.
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This anonymous class defined a method that is not directly invoked and does not override a method in a superclass. Since methods in other classes cannot directly invoke methods declared in an anonymous class, it seems that this method is uncallable. The method might simply be dead code, but it is also possible that the method is intended to override a method declared in a superclass, and due to an typo or other error the method does not, in fact, override the method it is intended to.
This anonymous class defined a method that is not directly invoked and does not override a method in a superclass. Since methods in other classes cannot directly invoke methods declared in an anonymous class, it seems that this method is uncallable. The method might simply be dead code, but it is also possible that the method is intended to override a method declared in a superclass, and due to an typo or other error the method does not, in fact, override the method it is intended to.
This anonymous class defined a method that is not directly invoked and does not override a method in a superclass. Since methods in other classes cannot directly invoke methods declared in an anonymous class, it seems that this method is uncallable. The method might simply be dead code, but it is also possible that the method is intended to override a method declared in a superclass, and due to an typo or other error the method does not, in fact, override the method it is intended to.
All writes to this field are of the constant value null, and thus all reads of the field will return null. Check for errors, or remove it if it is useless.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.
Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.
Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.
Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.
This method acquires a JSR-166 (java.util.concurrent) lock,
but does not release it on all paths out of the method. In general, the correct idiom
for using a JSR-166 lock is:
Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This cast is unchecked, and not all instances of the type casted from can be cast to the type it is being cast to. Ensure that your program logic ensures that this cast will not fail.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method. If the object is, indeed, non-serializable, an error will result.
This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method. If the object is, indeed, non-serializable, an error will result.
This operation compares two floating point values for equality.
Because floating point calculations may involve rounding,
calculated float and double values may not be accurate.
For values that must be precise, such as monetary values,
consider using a fixed-precision type such as BigDecimal.
For values that need not be precise, consider comparing for equality
within some range, for example:
if ( Math.abs(x - y) < .0000001 ).
See the Java Language Specification, section 4.2.4.
This operation compares two floating point values for equality.
Because floating point calculations may involve rounding,
calculated float and double values may not be accurate.
For values that must be precise, such as monetary values,
consider using a fixed-precision type such as BigDecimal.
For values that need not be precise, consider comparing for equality
within some range, for example:
if ( Math.abs(x - y) < .0000001 ).
See the Java Language Specification, section 4.2.4.
This operation compares two floating point values for equality.
Because floating point calculations may involve rounding,
calculated float and double values may not be accurate.
For values that must be precise, such as monetary values,
consider using a fixed-precision type such as BigDecimal.
For values that need not be precise, consider comparing for equality
within some range, for example:
if ( Math.abs(x - y) < .0000001 ).
See the Java Language Specification, section 4.2.4.
This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This method contains a switch statement where one case branch will fall through to the next case. Usually you need to end this case with a break or return.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This method call passes a null value to a method which might dereference it unconditionally.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method call passes a null value to a method which might dereference it unconditionally.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This method call passes a null value to a method which might dereference it unconditionally.
Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.
This cast is unchecked, and not all instances of the type casted from can be cast to the type it is being cast to. Ensure that your program logic ensures that this cast will not fail.
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class defines a method called hashcode(). This method
does not override the hashCode() method in java.lang.Object,
which is probably what was intended.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This method acquires a JSR-166 (java.util.concurrent) lock,
but does not release it on all paths out of the method. In general, the correct idiom
for using a JSR-166 lock is:
Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A class defines an equals(Object) method but not a hashCode() method, and thus doesn't fulfill the requirement that equal Objects have equal hashCodes. An instance of this class is used in a hash data structure, making the need to fix this problem of highest importance.
A class defines an equals(Object) method but not a hashCode() method, and thus doesn't fulfill the requirement that equal Objects have equal hashCodes. An instance of this class is used in a hash data structure, making the need to fix this problem of highest importance.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method call passes a null value to a method which might dereference it unconditionally.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method call passes a null value to a method which might dereference it unconditionally.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method call passes a null value to a method which might dereference it unconditionally.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This operation compares two floating point values for equality.
Because floating point calculations may involve rounding,
calculated float and double values may not be accurate.
For values that must be precise, such as monetary values,
consider using a fixed-precision type such as BigDecimal.
For values that need not be precise, consider comparing for equality
within some range, for example:
if ( Math.abs(x - y) < .0000001 ).
See the Java Language Specification, section 4.2.4.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This operation compares two floating point values for equality.
Because floating point calculations may involve rounding,
calculated float and double values may not be accurate.
For values that must be precise, such as monetary values,
consider using a fixed-precision type such as BigDecimal.
For values that need not be precise, consider comparing for equality
within some range, for example:
if ( Math.abs(x - y) < .0000001 ).
See the Java Language Specification, section 4.2.4.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class defines a covariant version of the equals()
method, but inherits the normal equals(Object) method
defined in the base java.lang.Object class.
The class should probably define a non-covariant version of equals().
(I.e., a method with the signature boolean equals(java.lang.Object).
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method call passes a null value to a method which might dereference it unconditionally.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
A non-serializable value is stored into a non-transient field of a serializable class.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A value stored in the previous switch case is overwritten here due to a switch fall through. It is likely that you forgot to put a break or return at the end of the previous case.
This method contains a switch statement where one case branch will fall through to the next case. Usually you need to end this case with a break or return.
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This method call passes a null value to a method which might dereference it unconditionally.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
This method call passes a null value to a method which might dereference it unconditionally.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method calls equals(Object) on two references, one of which is a class and the other an interface, where neither the class nor any of its non-abstract subclasses implement the interface. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
All writes to this field are of the constant value null, and thus all reads of the field will return null. Check for errors, or remove it if it is useless.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This code compares a value that is guaranteed to be non-negative with a negative constant.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This finalizer does nothing except null out fields. This is completely pointless, and requires that the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize method.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
A non-serializable value is stored into a non-transient field of a serializable class.
A non-serializable value is stored into a non-transient field of a serializable class.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
A non-serializable value is stored into a non-transient field of a serializable class.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class is an inner class of a non-serializable class. Thus, attempts to serialize it will also attempt to associate instance of the outer class with which it is associated, leading to a runtime error.
If possible, making the inner class a static inner class should solve the problem. Making the outer class serializable might also work, but that would mean serializing an instance of the inner class would always also serialize the instance of the outer class, which it often not what you really want.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class implements the Serializable interface
and its superclass does not. When such an object is deserialized,
the fields of the superclass need to be initialized by
invoking the void constructor of the superclass.
Since the superclass does not have one,
serialization and deserialization will fail at runtime.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
Signed bytes can only have a value in the range -128 to 127. Comparing
a signed byte with a value outside that range is vacuous and likely to be incorrect.
To convert a signed byte b to an unsigned value in the range 0..255,
use 0xff & b
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This anonymous class defined a method that is not directly invoked and does not override a method in a superclass. Since methods in other classes cannot directly invoke methods declared in an anonymous class, it seems that this method is uncallable. The method might simply be dead code, but it is also possible that the method is intended to override a method declared in a superclass, and due to an typo or other error the method does not, in fact, override the method it is intended to.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This anonymous class defined a method that is not directly invoked and does not override a method in a superclass. Since methods in other classes cannot directly invoke methods declared in an anonymous class, it seems that this method is uncallable. The method might simply be dead code, but it is also possible that the method is intended to override a method declared in a superclass, and due to an typo or other error the method does not, in fact, override the method it is intended to.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This anonymous class defined a method that is not directly invoked and does not override a method in a superclass. Since methods in other classes cannot directly invoke methods declared in an anonymous class, it seems that this method is uncallable. The method might simply be dead code, but it is also possible that the method is intended to override a method declared in a superclass, and due to an typo or other error the method does not, in fact, override the method it is intended to.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This method unconditionally invokes itself. This would seem to indicate an infinite recursive loop that will result in a stack overflow.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This cast will always throw a ClassCastException.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This code compares a value that is guaranteed to be non-negative with a negative constant.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This cast will always throw a ClassCastException.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The referenced methods have names that differ only by capitalization or the packages of their parameters. This is very confusing because if the capitalization and parameter package names were identical then one of the methods would override the other.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This code creates a java.util.Random object, uses it to generate one random number, and then discards the Random object. This produces mediocre quality random numbers and is inefficient. If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number is required invoke a method on the existing Random object to obtain it.
If it is important that the generated Random numbers not be guessable, you must not create a new Random for each random number; the values are too easily guessable. You should strongly consider using a java.security.SecureRandom instead (and avoid allocating a new SecureRandom for each random number needed).
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
Signed bytes can only have a value in the range -128 to 127. Comparing
a signed byte with a value outside that range is vacuous and likely to be incorrect.
To convert a signed byte b to an unsigned value in the range 0..255,
use 0xff & b
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This cast will always throw a ClassCastException.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This cast will always throw a ClassCastException.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
This cast will always throw a ClassCastException.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.
Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.
Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.
This method unconditionally invokes itself. This would seem to indicate an infinite recursive loop that will result in a stack overflow.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.
Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
See the Java Language Specification for details
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information.
Consider using java.net.URI instead.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or java.lang.Object, and does not appear to implement
the Externalizable interface or the
readObject() and writeObject() methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class defines a method called hashcode(). This method
does not override the hashCode() method in java.lang.Object,
which is probably what was intended.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This method contains a self assignment of a local variable; e.g.
public void foo() {
int x = 3;
x = x;
}
Such assignments are useless, and may indicate a logic error or typo.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.
You may also experience serialization problems.
Using an instance field is recommended.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
This method compares a local variable with itself, and may indicate a typo or a logic error. Make sure that you are comparing the right things.
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., if (x == Double.NaN)). However,
because of the special semantics of NaN, no value
is equal to Nan, including NaN. Thus,
x == Double.NaN always evaluates to false.
To check to see if a value contained in x
is the special Not A Number value, use
Double.isNaN(x) (or Float.isNaN(x) if
x is floating point precision).
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,
String dateString = getHeaderField(name); dateString.trim();
the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:
String dateString = getHeaderField(name); dateString = dateString.trim();
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is Integer.MIN_VALUE, then the result will be negative as well (since
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A reference value dereferenced here might be null at runtime.
This may lead to a NullPointerException when the code is executed.
The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The referenced methods have names that differ only by capitalization or the packages of their parameters. This is very confusing because if the capitalization and parameter package names were identical then one of the methods would override the other.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This class defines a covariant version of the equals()
method, but inherits the normal equals(Object) method
defined in the base java.lang.Object class.
The class should probably define a non-covariant version of equals().
(I.e., a method with the signature boolean equals(java.lang.Object).
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This operation compares two floating point values for equality.
Because floating point calculations may involve rounding,
calculated float and double values may not be accurate.
For values that must be precise, such as monetary values,
consider using a fixed-precision type such as BigDecimal.
For values that need not be precise, consider comparing for equality
within some range, for example:
if ( Math.abs(x - y) < .0000001 ).
See the Java Language Specification, section 4.2.4.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This method invokes the .equals(Object o) to compare an array and a reference that doesn't seem to be an array. If things being compared are of different types, they are guaranteed to be unequal and the comparison is almost certainly an error. Even if they are both arrays, the equals method on arrays only determines of the two arrays are the same object. To compare the contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This code compares java.lang.String objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the String.intern() method, the same string
value may be represented by two different String objects. Consider
using the equals(Object) method instead.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class implements the Serializable interface, but does
not define a serialVersionUID field.
A change as simple as adding a reference to a .class object
will add synthetic fields to the class,
which will unfortunately change the implicit
serialVersionUID (e.g., adding a reference to String.class
will generate a static field class$java$lang$String).
Also, different source code to bytecode compilers may use different
naming conventions for synthetic variables generated for
references to class objects or inner classes.
To ensure interoperability of Serializable across versions,
consider adding an explicit serialVersionUID.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an if statement, e.g.:
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The referenced methods have names that differ only by capitalization or the packages of their parameters. This is very confusing because if the capitalization and parameter package names were identical then one of the methods would override the other.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This class defines a covariant version of the equals()
method, but inherits the normal equals(Object) method
defined in the base java.lang.Object class.
The class should probably define a non-covariant version of equals().
(I.e., a method with the signature boolean equals(java.lang.Object).
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
A null pointer is dereferenced here. This will lead to a
NullPointerException when the code is executed.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.
In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method. If the object is, indeed, non-serializable, an error will result.
This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method. If the object is, indeed, non-serializable, an error will result.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.
This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This code compares a java.lang.String parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the equals(Object) method instead.
This class overrides equals(Object), but does not
override hashCode(), and inherits the implementation of
hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object
by the VM). Therefore, the class is very likely to violate the
invariant that equal objects must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}